Providing new functionality in an operating system platform can be a difficult and problematic endeavor. Typically, it requires modifying or replacing hard-coded platform components and the application program interface(s) (API(s)) associated with those components. For instance, consider a new operating system platform version which includes an upgraded color management system which provides additional or more sophisticated color processing functionality capable of utilizing new image data and associated metadata. Usually, those APIs in the API module associated with this new functionality and data/metadata are changed so as to be able to recognize and accommodate this new information. Such changes, however, typically cause compatibility problems with respect to legacy applications and/or devices designed to run on the legacy API(s) that are being changed. To remain compatible with the API(s), device vendors are thus often forced to replace or modify their products—which typically entails becoming familiar with the new or modified APIs in the API module before making the necessary programmatic changes.
While some solutions exist, such as treating legacy objects as legacy objects and treating advanced objects as advanced objects, vendors still have the burden of modifying or replacing their applications/devices each time a new version is released, which typically limits modifications and replacements to a single upgrade process.